University of Konstanz - KOSAI

VAST 2011 Challenge
Mini-Challenge 2 – Computer Networking Operations at All Freight Corporation

Authors and Affiliations:

Mark Tautzenberger, University of Konstanz, mark.tautzenberger@uni-konstanz.de
Thomas Lindemeier, University of Konstanz, thomas.lindemeier@uni-konstanz.de
Stephan Huber, University of Konstanz, stephan.huber@uni-konstanz.de
Fabian Fischer, University of Konstanz, fabian.fischer@uni-konstanz.de
Florian Mansmann, University of Konstanz, florian.mansmann@uni-konstanz.de



Tool(s):

The preprocessing of the data was done with KNIME [www.knime.org], a tool which can also be used for data analysis and mining. However we also used Microsoft Excel and wrote our own programs in C++ for additional preprocessing.

Wireshark [www.wireshark.org] was used to gain insight into the PCAP data.

The analysis of the relations in network data is usually realized through graph visualizations. Therefore we used Gephi [www.gephi.org] to visualize the relations of the All Freight network.

As part of the challenge we developed our own software, which we called KOSAI (Konstanzer Situational Awareness Interface). It operates on a MySQL [www.mysql.com] database where the data is stored.

We used Tableau [www.tableausoftware.com] to do a detailed visualization and analysis of the events discovered with KOSAI.

 

Video:

Video

 

ANSWERS:

MC 2.1 Events of Interest: Using the new situation awareness display(s), what noteworthy events took place for the time period covered in the firewall, IDS and syslog logs? Which events are of concern from a security standpoint? Limit your answer to no more than five noteworthy events. For each event, at least one of the submitted screen shots must be relevant in your explanation of the event.

We implemented our own application to visualize the given datasets, called KOSAI. It is based on a matrix visualization. Each cell represents a relation between a source (row) and a destination (column) IP over time. The upper part of the cell shows the number of built connections in a green color tone. The lower part displays the number of IDS alerts in a red color tone. It was developed concurrently while analyzing the given data with Tableau.Together with Tableau, it represents our situational awareness interface. Due to the chronological order of the given data we first had a look into the preprocessed Nessus file. We found out that five workstations (IPs 192.168.2.171 - 175) were classified as vulnerable. The report said that because of missing updates, arbitrary code could be executed from outside the network on these workstations. We will refer to these addresses in the following as suspicious IPs.

 


Figure 1) A bar chart of the IDS alerts over the three days. There are different kind of alerts in the IDS logs, but the TCP-window-scale alerts (depicted in red) stand out extremely. They were performed by the suspicious IPs on April 13th and 14th .

 

Our first event is the TCP-window-scale alerts, logged in the IDS files (see Fig. 1). We classify these scales as an attack because they enable the initiator to execute arbitrary code on attacked machines. We discovered this event by plotting all recorded alerts over the given three days in Tableau and counting their individual number. We consider this as an event of high concern for the security of the network, because combined with the information from the Nessus scan it implies that these workstations could have been hacked.

We discovered our second event by checking the connections to and from the Snort IDS server (192.168.1.16) with KOSAI. Since this server only hosts the snorting software we expected to see no connections to it. But we found connections from two of the suspicious IPs in the matrix view (see fig. 2). We consider this event as of great interest because it indicates that someone could have broken into the network and later tried to erase his traces.




Figure 2) The suspicious IP 192.168.2.174 connects the IDS Server at 09:05:47 resulting in window scale alerts (see lower detail window). Later that day, at 10:44:57, it established another single connection to the IDS server.

 

When we loaded the preprocessed security logs in Tableau and had a look at all logged events and their chronological distribution over the three days, we discovered our third event. In Fig.3, there are some events, which are logged seamlessly throughout the whole time period, e.g. successful logins and logouts. But we identified the failed logon attempts as the most important because they appear often but only during a short time window. Furthermore, it is a system logon on the web server, which should never fail. We do not classify this event as critical from a security standpoint because the server might be simply down due to software or administrative issues and some service might have tried to retrieve some data from the server.

 


Figure 3) The different events listed in the security logs and their distribution over the three days. Notice the failed logon attempts (red) from around 1:34 am to 14:30 am on April 15th .



By scrolling down the list of connections of the workstations in KOSAI, we detected that there exists the IP 192.168.2.251. According to the provided network description document, it is not part of the legitimate DHCP address pool range (192.168.2.10-250). Furthermore, from this IP a connection was established to the external web server, which then immediately connected to the shipping server (192.168.1.4). Fig. 4 explains the detection of this event in more detail. This could be an event of interest for security reasons because this IP built only one single connection during the whole three days and exactly this connection is built to the shipping server through a port which is used by SQL services.

 


Figure 4) In this Figure you can see that a single connection from “192.168.2.251” to “172.20.1.5” has been established (yellow marks). a) By taking a look in the firewall data of this connection it is possible to extract the time windows in which the connection was established. The next step is to adjust the time window of the visualization corresponding to the extracted time window. b) The updated visualization shows a connection from “172.20.5.1” to the shipping server on SQL port 1433 (red marks). The two connections occur in the same second from which we conclude that “192.168.2.251” executed a database query on the shipping database server.



As the 5th and last event we want to mention a remote desktop connection, which we classified as highly important with regard to security reasons. Again while scrolling over the rows of KOSAI we discovered a workstation from the internet connecting to the external web server on port 3389, which then immediately connected to the internal web server and to the shipping server on the windows shared ports. The complete path of this connection is visualized in Fig 5. According to corporate user acceptable policy, remote desktop connections are forbidden, which is why we classify this event as of high concern with regard to security reasons.




Figure 5) In a) we can see a message flooding attack from IPs from the internet. To avoid that these connections suppress the visualization of other connections from the same row/col pair, there is an option in KOSAI to show only the existence of a connection and not the amount of connections. This makes it possible to detect some connections from “10.200.150.201” after the message flooding, which are illustrated in b). After filtering the time window, we can see that the external web server connects shortly after a remote desktop connection (port 3389) to the shipping database server and the internal web server on port 445, which is used by windows shares.

 

 

MC 2.2 Timeliness: For each event submitted in MC 2.1, how early in the course of the event would your display(s) enable a CNO team member to recognize that the event was noteworthy? For each event, specify the earliest moment of recognition as a time-stamp and provide a screen shot at the earliest moment of recognition. Explain how the CNO team member had enough information to determine that the event warranted attention.

KOSAI could be used online. The visualization updates every time something has been logged. The CNO is expected to look at the visualization in a regular manner, e.g. once an hour, to check if something is going on. Furthermore, any CNO team member could define some rules for every cell (which stands for relations of IPs). If a rule was violated, KOSAI would inform the CNO that something noteworthy has happened.



The first event submitted in 2.1 was the TCP window scale on all workstations, even non-existing ones. In KOSAI you can identify this event in the “all workstations” column, as shown in Fig 1. By viewing the detailed IDS view, you see the id 4 in the “snort” column, which stands for TCP window scale attacks. The earliest time stamp provided there is 11:17:37am on Wednesday the 13th. The CNO would have recognized this event as noteworthy because the workstation, which did the TCP window scales, was classified two days earlier as vulnerable to outside attacks by the Nessus scan. Therefore the font of these IPs is colored in red. KOSAI would have informed the CNO right after the Nessus scan on April the 11th , that these IPs are suspiciuos. So a member of the CNO should have defined a notification rule for these IPs. Therefore this event could have been detected immediately when the first alert occured.




Figure 1) The detailed view for the IDS alerts show the earliest time-stamp while simultaneously highlighting the source IP in red color, which means classified as vulnerable by the Nessus scan.

 

The second submitted event is documented in the Tableau visualization, which shows the exact time of the connections to the Snort IDS server. The earliest connection can be seen in Fig. 2 at 09.05.47am on April 14th. The CNO team member knows that this is an important event by the fact that normally no computer should connect to the IDS-server. Furthermore the two IPs connecting to the server were already classified as vulnerable to remote code execution by the Nessus scan. If there was a rule defined which states that every connection to the IDS-server is suspicious, this event could haven been quickly noticed at the timestamp of the first connection.



Figure 2) The connections to the Snort IDS server, which is expected to be not connected by workstations or other servers.

For our third event we must admit that KOSAI cannot detect the event. We did not include the security logs in it because we decided to design a Tableau worksheet for this task. However, we found this event in the first part of our analysis process with Tableau by visualizing all logged event IDs over the entire timespan. The earliest moment of recognition for this event would have been on Thursday the 15th at 01:34:58am as it is shown in Fig. 3. Because the failed logon attempts are in close chronological order the CNO team member should have identified this event as of high importance.




Figure 3) The security logs for all 3 days visualized in Tableau. The red events are the failed logon attempts.



For the fourth event, the unknown IP address “192.168.2.251”, which should not even exist in the network and has connected to the external web server, can effortlessly be seen easily in KOSAI. There are very few connections to the web server and the few ones stand out. The time-stamp for this connection is 2:06:26pm on April 15th (see Fig. 4). Any member of the CNO should be aware of the fact, that this IP lies outside the specified range of IP addresses and therefore classify this as a noteworthy event. KOSAI knows the range of the workstation subnet and would inform the CNO member right when the connection is built.




Figure 4) The unknown IP can be recognized in KOSAI (yellow circle).The detailed firewall data view shows the exact timestamp.

 

The last event of interest we discovered in 2.1 was the remote desktop connection from the internet to All Freight Corporation's external web server. The earliest moment of recognition in KOSAI would be April 13th at 4:44:50pm. A team member would have paid this event some attention because the connection came from the internet and tried to connect on port 3389 which is forbidden by the acceptable user policy. The forbidden ports are defined in rules, therefore whenever a connection to such a port is built from the outside, KOSAI informs you about it.



Figure 5) The connection from the internet to the external web server which was hidden in other port scan connections. The server then connected to the internal web server and the shipping database server.



MC 2.3 Recommendations: What are the implications of the events discovered in MC 2.1? What report should the CNO give to the CEO and/or what actions should the CNO take to improve security?

The implications of the discovered events are that All Freight Corporation network was hacked. The CNO should report that it is likely that somebody got access to the network and stole or manipulated confidential data from the shipping or internal web server. These events happened because the security holes weren't detected soon enough, maybe because of missing manpower. Therefore our situational awareness display should be used because it enables the early detection and investigation of noteworthy events, which in the end saves manpower.

We recommend the CNO team to have the following things done to improve security: